Happy to work on test fixes, if the PR itself makes sense :)

@grimmySwe, @plach79, I'm pretty sure I want this.

@grimmySwe, I'm going to wait on your feedback here and on #313, but I think
this is needed before we can release 0.4.0.

I definitely want tests for it.

If we want update-on-push behavior we can add it as a config option. I think
post-0.4.0 we will want to rely more on git config options for the subrepo
section of git config files. That means they will work the same as other git
config options, and people can do them per repo, per user, per machine etc.

Of course we still need to hear from @grimmySwe that new subrepo functionality
will work without updating.

We are using same kind of workflow as @plach79 and need to push different branches in subrepos.
git-subrepo complains as @plach79 explains in #313, even if we work only in the monorepo.

Our workflow :

• create a monorepo with all our projects

git subrepo clone projectA projectA
git subrepo clone projectB projectB
git subrepo clone projectC projectC
git push upstream master

• team member forks and clones the monorepo

git clone my/monorepo
git remote add upstream our/monorepo

• team member works on the monorepo

git checkout -b feature/multi-projects develop
git commit
git push origin feature/multi-projects

• PR, code review, ... then release

git checkout develop
git merge upstream/feature/multi-projects
git branch release/multi-projects
git push upstream release/multi-projects

As our deployment processes are currently linked to our subrepos, we need to keep them in sync to deploy and test our release.

• push the release branch to subrepos

git subrepo push projectA -b release/multi-projects
git subrepo push projectB -b release/multi-projects
git subrepo push projectC -b release/multi-projects

Here, without #314, subrepos/.gitrepo files are updated to track the release/multi-projects branches.

• deploy the release, test, fix and PR on the release branch

git checkout release/multi-projects
git commit
git push release/multi-projects

• push fixes on the release branch to subrepos

git subrepo push projectA -b release/multi-projects
git subrepo push projectB -b release/multi-projects
git subrepo push projectC -b release/multi-projects

When we are happy with the release, we merge the release into master.

• merge release into master

git checkout master
git merge upstream/release/multi-projects
git push upstream master

Now we want to deploy it to production and need to push our master branch to subrepos.

• push the master branch to subrepos

git subrepo push projectA -b master -u
git subrepo push projectB -b master -u
git subrepo push projectC -b master -u

Without #314, this last step fails as the subrepos/.gitrepo files are now tracking the release/multi-projects branches, and we cannot push anymore to the master branches.

@aya Very good description of the use case! Thank you.

Can you target this PR against master? The release/0.4.0 branch has now been merged.

@ingydotnet

Can you target this PR against master? The release/0.4.0 branch has now been merged.

Sorry, I completely missed your reply. I just rebased the PR onto master and pushed it. I can look into test failures if you're still interested in merging this.

I have a feeling this pull request changes too much. Without -u, I would expect the commit and parent values to still be updated. There is already code in update-gitrepo-file to respect -u, but it seems to be broken.

Is there any chance to merge this fix?

Implicitly enabled -u option does not make sense when subrepo push is done into a PR branch, because that branch is going to be removed once PR is merged and "commit" field becomes invalid.

Simple test of pull without "git subrepo push" update commit works ok for me - it is able to add only new commits from subrepo.

On the other hand, if you want -u by default for some reason, it would be nice to have an option to disable it...

My idea is to remove the automatic "pull" during a subrepo push. Most of the projects I use subrepo with these days have a pr mechanism (like gerrit) that modify the patch before it is added to the target repo. I think the correct idea is to do the push, then the maintainer would have to do a pull after the merge has completed. Maybe an option to automatically pull in the push for those that are accustom to the existing behavior.